home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000039_news@newsmaster….columbia.edu _Fri Jan 2 20:50:38 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id UAA27653
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Fri, 2 Jan 1998 20:50:38 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id UAA18573
  7.     for kermit.misc@watsun; Fri, 2 Jan 1998 20:50:37 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: K/2 Gotchas
  12. Date: 3 Jan 1998 01:50:34 GMT
  13. Organization: Columbia University
  14. Lines: 95
  15. Message-ID: <68k5ha$4kf$1@apakabar.cc.columbia.edu>
  16. References: <TCPSMTP.18.1.2.-16.50.0.2375661496.4897539@kincyb.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8205
  19.  
  20. In article <TCPSMTP.18.1.2.-16.50.0.2375661496.4897539@kincyb.com>,
  21.  <dallasii@kincyb.com> wrote:
  22. : ...
  23. : 2) My command files for exchanging email packages keep records
  24. : of what happens in a file in RAM disk.  At the end of the command file
  25. : 
  26. : run TYPE MAILTEMP.TMP >> C:\QWK\RECORD.LOG
  27. : 
  28. : is run to keep a permenant record of transactions.
  29. : This command ran on MS-DOS 3.14 but was causing problems when I
  30. : ran the command file on Kermit/2, with 'SYSxxxx   File name too long'
  31. : and such coming from the OS.  I finally tracked this down to the need to
  32. : change the command to
  33. : 
  34. : run TYPE MAILTEMP.TMP >> C:\\QWK\\RECORD.LOG
  35. : 
  36. : On MS-DOS Kermit 3.14, the single back slashes were permitted even though
  37. : the documentation clearly states that a double back slash should be used
  38. : when a back slash is desired where escaped substitution occurs.
  39. : 
  40. One of the most aggravating thing about script languages -- all of them,
  41. not just Kermit's -- is that certain characters inevitably become overloaded,
  42. hence the annoying quoting rules.  In the case of Kermit 95 and K/2, we try
  43. our best to let you type pathnames with single backslashes or, for that
  44. matter, with forward slashes instead of backslashes, but we can only do that
  45. when Kermit itself is parsing the filename (even then it's guesswork at best;
  46. if you type "c:\%a" is "\%a" a Kermit variable or an actual pathname?).
  47. But obviously, Kermit can not parse the RUN command (at least not the part
  48. past the word "RUN" -- it's just a text string to Kermit).  So backslashes
  49. here must be doubled.
  50.  
  51. The irony is that Windows 95, Windows NT, and OS/2 all support forward slashes
  52. as directory seprators at the OS API level -- it is only their command shells
  53. that get in the way.  Why?  Because they have the same problem we do: the
  54. overloading of characters.  In DOS-like command shells, "/" introduces a
  55. "switch", so "dir /b" means "a brief directory listing" rather than a listing
  56. of the files int the top-level B directory.
  57.  
  58. But yes, all of this is well documented.  The C-Kermit manual even has a
  59. section devoted to "Taming the Wild Backslash".
  60.  
  61. Some day we'll look back on all this and laugh.
  62.  
  63. : 3) When the command file got to the point where the mail package was being
  64. : generated, the BBS generates a stream of
  65. : 
  66. : ^H|^H/^H-^H\^H|^H/^H-^H\^H...........
  67. : 
  68. : to indicate that things are not dead while the package is prepared.
  69. : This seemed to spas out the command file when run in Kermit/2, but
  70. : not MS-DOS Kermit.  The problem was eliminated when the input buffer was
  71. : increased from the default minimum size (256 bytes) to the maximum size
  72. : (65,536 bytes).  I noticed that there was a listing in BUGS.TXT that the
  73. : "input buffer was too small".  I don't think I have anything special about
  74. : the input buffer for my MK 3.14, so I conclude that either
  75. : 
  76. : a) the circular buffer works with MK 3.14 and not with K/2
  77. : 
  78. That can't be true, or we'd have been pilloried by angry mobs years ago.
  79.  
  80. : or
  81. : 
  82. : b) the ^H's effectively erase characters already in the input buffer
  83. :    in MK 3.14 but not with K/2
  84. : 
  85. No.  Bytes go into the buffer, no matter what they are (except NUL).
  86.  
  87. What is the syntax of your INPUT command?
  88.  
  89. : 4)  Another problem was that a script seemed to stop, then fail on
  90. : 'reinput' of a string that was obviously being recieved.  The real problem
  91. : turned out to be in an earlier 'input' command.  The Gotcha! in this case
  92. : was that besides going between versions of Kermit, there were two modems
  93. : involved...
  94. :
  95. Well, this kind of script programming is a lot easier now that both K95 (K/2)
  96. and MS-DOS Kermit support the MINPUT command (INPUT looks for Many things at
  97. once).  There is virtually no longer any need for REINPUT.
  98.  
  99. : 5)  Another problem was brought on when a dialup
  100. : script ran.  Everything went OK until I went to connect mode.
  101. : Then, as soon as anything was entered from the keyboard, K/2
  102. : left connect mode back to command mode, the session froze up,
  103. : the cursor went to lower left-hand corner and the session seemed to become
  104. : unkillable.  Any effort to stop the session would produce a message at the
  105. : bottom of the screen, something to the effect of
  106. : "!!! Recieved Kill Signal!!!", but the session lived on, hogging the
  107. : COM port, still locked up until reboot.
  108. :
  109. If you can reproduce this ("!!! Recieved Kill Signal!!!" is not one of our
  110. messages), you should contact kermit-support@columbia.edu and we'll see if
  111. we can figure out what's what.  Obviously Kermit should not hang, and you 
  112. should not need to reboot your PC to get the COM port back.
  113.  
  114. - Frank